I guess differentiating them is maybe deceptive since the executable is deleted each time, unlike the MSBuild executables who can coexist in their directory. Suppose it doesn't matter.

Sorry, but this breaks compatibility with other ides due to creating conditional build targets (which is just bad practice in general). The meson launch option is also very much not meant to build release, since custom build options are frequently useful and necessary.

I don't know what IDE you use or if you just debug your game from the terminal, but as is the default configurations don't work for VSCode. I also don't really know anything about these systems, obviously, I'm only working on it because it doesn't work on my system.

The Meson configurations already expected CortexCommand_debug, which didn't get created by their pre-launch tasks, and so while it might have been a wiser solution to just make them expect CortexCommand, I had the builds make further differentiation to parallel what we were doing with MSVC builds, then changed the configurations to expect this differentiation. Should I instead have all Meson configs for Unix expect CortexCommand? If so, why don't the Windows configurations do the same (Cortex Command.debug.minimal.exe and such)? In any case, why does meson Launch have Meson: Build all targets as pre-launch task, where meson Launch [Windows] has meson Build Release? I assumed this asymmetry, which did cause me trouble only once I had brought everything to make conditional build targets, was unintentional.

All of that is pretty much because I was the only one using the vscode config, and the workflows I need conflicted with the existing vscode tasks. I just forgot about the rest of the launch tasks, since they're basically useless once you understand how to use meson. CortexCommand_debug hasn't existed for 5 or 6 years now, so it's been at least that long since anybody's tried.
I haven't worked on the windows meson build for a long time since nobody uses it (apart from CI) so things there aren't in an up to date state. Initially I had built it to mimic the msvc build as closely as possible, which is why it's full of bad decisions.

I've been putting some thought into it recently for maybe replacing msbuild entirely since it's not great having two separate build systems in place (and the msbuild files are horrendous to work with without visual studio) which would address the disparities between *nix and windows.